1. Technical Field
The present invention relates in general to improved file system management. Still more particularly, the present invention relates to managing a snapshot within a file system space for efficient detection of in-use blocks.
2. Description of the Related Art
A file system is a mechanism for storing and retrieving files on a disk. A file system defines the directory for keeping track of the files and the path syntax required to access the files. The file system also defines the way files are named and limits the maximum file size of the file or volume. A file system generally consists of two distinct parts: a collection of files and a directory structure. Each file in the collection of files stores related data. The directory structure organizes and provides information about the files in the file system.
An important attribute of a system that supports a file system, is the backup support for the file system. In one example, a snapshot function of an operating system maintains a read-only copy that reflects the state of the file system at the time of creation of the file system snapshot. A backup of the snapshot can be created for recovery purposes.
In particular, a file system snapshot establishes a consistent block level image of the blocks of the file system at a point in time. A block is a group of data that is transmitted or processed together at the same time. A block is also referred to as a data block.
A file system snapshot copies the modified blocks which were in use in the file system at the point in time when a snapshot was created in order to maintain the point in time image. In one example, a file system maintains a bitmap file, also referred to as a bMap, to track the allocation state of the blocks in the file system. In addition, the bMap can be checked by the snapshot controller to determine whether a block was in use at the time a snapshot was created.
If the snapshot is written to a device separate from the file system, then the blocks allocated for the snapshot are not tracked by the bMap of the file system. In this example where the snapshot is written to a device separate from the file system, the snapshot controller can easily preserve a copy of the file system at a point in time based on the bMap because an update to the snapshot does not update the bMap.
In contrast, when a snapshot is written within the file system space itself, the blocks allocated to the snapshot are also tracked in the bMap of the file system. Tracking blocks allocated to the snapshot in the bMap within the file system creates the potential for recursion when attempting to maintain the snapshot. For example, a block being allocated is tracked by a bMap page. When the allocation of the block is the first modification of the bMap page since the snapshot was created, the point in time image of the bMap page must be copied in order to preserve the point in time image of the bMap page. To copy the point in time image of the bMap page into the snapshot, the file system must allocate additional blocks to the snapshot, resulting in further modification of the bMap pages in the file system, and triggering recursive iterations of block allocations and updates to the bMap page.
In view of the foregoing, there is a need for a method, system, and program, when a snapshot is written to the file system space, to determine the in use state of blocks of the file system for managing a point in time snapshot, separate from the bMap which tracks allocations of blocks within the file system.